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1 .  INTRODUCTION 


1.1  General 


This  report  is  the  Final  Technical  Report  for  the  lAF  Geographical 
Data  Processing  System  (GDPS) .  The  information  herein  is  in  fulfillment 
of  the  obligations  set  forth  in  Contract  No.  F30602-78-C-0278.  Companion 
documents  which  provide  additional,  very  detailed  technical  information 
are : 

a.  Geographical  Data  Processing  System  Computer  Program 
Documentation  Manual  (Volumes  I  and  II) 

b.  lAF  Geographical  Data  Processing  System  (GDPS)  Design 
Plan 

c.  GDPS  Operation  Manual 

d.  Test  Plan/Procedures  for  lAF  Geographical  Data 
Processing  System  (GDPS) 

1.2  Background 

In  1976,  Synectics  developed  the  Cartographic  System,  in  an  effort 
sponsored  by.RADC,  for  the  Italian  Military  Geographies  Institute  (IGMI). 
This  effort  was  conducted  under  the  auspices  of  the  joint  USAF/Italian 
Air  Force  (lAF)  Cooperative  Research  and  Development  program.  The  CS  was 
designed  to  aid  in  the  chart  compilation  process.  With  the  advent  of  the 
Digital  Landmass  Simulation  (DLMS)  program,  a  requirement  was  placed  on 
all  NATO  members  to  collect  terrain  and  planimetric  (culture)  data  over 
their  respective  countries.  It  was  decided  that,  while  the  CS  was  adequate 
for  collecting  digitized  data  from  charts,  it  could  not  support  the  high 
degree  of  processing  required  to  create  DLMS  digital  products.  Thus,  a 
second  system,  the  GDPS,  would  be  implemented  to  support  the  conversion  of 
digitized  output  to  DLMS  formats.  In  addition,  the  GDPS  would  have  its 
own  digitizing  subsystem,  the  GDPS-DS  to  worlt  in  parallel  with  the  CS  to 
allow  more  rapid  acquisition  of  chart  inputs. 


1 ■ 3  Scope 

The  scope  of  the  lAF-GDPS  effort  included  all  activites  required  to 
specify,  design,  fabricate,  procure,  integrate,  and  test  a  hardware  and 
software  system  which  met  the  functional  requirements  defined  in  the  State¬ 
ment  of  Wor]<.  The  basic  requirement  was  that  the  GDPS  produce  data  which 
is  totally  compatible  with  that  produced  by  the  DMAAC  DLMS  processing 
software.  Specifically,  this  data  constitutes  two  products:  terrain  and 
culture  input  tapes  to  the  DMA  Cartographic  Data  Base.  These  products 


must  be  constructed  according  to  the  following  guidelines: 


a.  Terrain  Data  Base  File  Tape: 

DMA  STANDARD  TERRAIN  FORMAT  (PS/ I C/OCTOBER  1977) 

b.  Culture  Data  Base  File  Tape: 

DMA  STANDARD  EXCHANGE  FORMAT  FOR  LINEAR  DIGITAL  DATA 
(MAY  1980) 


1.4  Objectives 

The  objectives  of  this  report  are  as  follows: 

a.  To  describe  the  approach  and  design  talcen  to  successfully 
fulfill  the  Scope  of  the  effort. 

b.  To  synopsize  the  testing/evaluation  activity. 

c.  To  specify  additional  system  enhancements. 

d.  To  suggest  the  role  which  the  GDPS  (or  other  similar 
systems)  could  fulfill  at  RADC  and  at  the  Defense  Mapping 
Agency  (DMA)  production  centers. 


2.  SYSTEM  OVERVIEW 


2.1  Subsystem  Concept 

As  outlined  in  the  Statement  of  Work,  the  GDPS  is  based  on  a  subsystem 
concept.  One  subsystem,  the  GDPS  Digitizing  Subsystem,  GDPS-DS,  supports 
data  acquisition  of  DLMS  analyst-prepared  inputs.  The  second  subsystem, 
the  DLMS  Processing  Subsystem,  DLMS-PS  is  used  to  process  GDPS-DS  output 
data  into  DLMS  terrain  and  culture  Cartographic  Data  Base  magnetic  tape 
input  files. 


2.2  GDPS-DS  Role 


The  GDPS-DS  uses  prepared  chart  manuscripts  and  Feature  Analysis 
Data  Table  (FADT)  information  (feature  header  descriptions  for  culture 
data)  as  input.  Processing  data  through  the  digitizing  and  FADT  soft¬ 
ware  modules  results  in  the  following  products  being  generated: 

a.  Digitized  Terrain  File 

b.  Digitized  Planimetric  (Culture)  File 

c.  FADT  File 

The  FADT  file  may  be  merged  with  the  Culture  file  at  either 
the  GDPS-DS  or  DLMS-PS.  The  action  of  this  merging  operation  results 
in  a  culture  file  in  the  same  format  as  that  of  an  unmerged  culture 
file . 


2.3  DLMS-PS  Role 

The  digitized  terrain  file  or  merged/digitized  culture  file  are 
used  as  sources  to  the  terrain  and  culture  file  software  packages 
respectively.  The  terrain  file  is  converted  to  the  DMA  Standard  Terrain 
Format,  and  then  merged  as  a  subset  to  a  one-degree  square  coverage  file. 
Once  the  file  has  been  completed,  it  may  be  output  to  tape  as  a  Carto¬ 
graphic  Data  Base  input.  The  culture  data  input  is  converted  to  the  DMA 
Standard  Exchange  Format  for  Linear  Data,  after  undergoing  various  re¬ 
construction  activities.  The  file  is  then  converted  to  tape  where  it  may 
subsequently  be  input  to  the  Cartographic  Data  Base. 

The  DLMS-PS  supports  the  production  of  both  Level  1  and  Level  2  DMA 
Standard  Format  products  for  terrain  and  culture  data. 


Data  Flow  Description 


Figure  2-1  is  an  illustration  describing  the  GDPS  data  flow.  The 
flow  begins  with  the  receipt  of  a  DLMS  manuscript  and  FADT  data  sheets 
(if  a  culture  job  is  being  processed) .  The  chart  data  is  digitized  using 
the  GDPSEX  digitizing  software  package.  In  parallel  with  this  activity, 
the  FADT  data  is  entered  on  the  system  through  use  of  a  psuedo-text  editor. 
Files  result  from  all  of  these  processes.  The  files  are  identified  by 
a  job  name  used  to  identify  the  activity  session  (digitizing  or  FADT  entry) . 
Once  these  operations  are  completed,  the  FADT  data  file  is  merged  with 
the  digitized  file  (for  culture  jobs  only).  The  resultant  digitized  file, 
terrain  or  culture,  is  output  to  magnetic  tape  and  subsequently  input  to 
the  DLMS-PS.  Depending  on  the  source  type,  i.e.  culture  or  terrain,  the 
files  are  transformed,  manipulated,  and  converted  to  either  of  two  DMA- 
specified  formats. 
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Figure  2-1.  GDPS  System  Data  Flow 


3.  HARDWARE  OVERVIEW 


3.1  GDPS  Subsystem  Configuration  Concept 

The  GDPS  hardware  has  been  configured  as  two  separate  subsystems. 
The  GDPS-DS  hardware  is  intended  to  support  all  digitizing  activities, 
while  the  DLMS-PS  hardware  will  support  DLMS  digital  format  conversion 
processes.  Each  subsystem  is  independent  of  the  other.  There  are  built 
in  compatibilities,  however,  within  the  system  that  allow  sharing  of 
hardware  resources.  They  are  as  follows: 

a.  Compatible  7-track  magnetic  tape  units; 

b.  Compatible  10-megabyte  disk  drives  which  nermit 
the  transfer  of  disk  cartridges  from  one  suasystem 
to  the  other; 

c.  A  common  plotter  which  is  switch-selectable  to 
either  subsystem;  and 

d.  A  common  display  screen  hardcopy  unit  which  can  be 
multiplexed  to  both  subsystem  Tektronix  display 
units . 

Figure  3-1  illustrates  the  total  GDPS  configuration. 

3.2  GDPS-DS 

The  following  information  pertains  to  the  hardware  configuration  of 
the  GPDS-DS  (Digitizing  Subsystem) .  A  roster  delineating  the  hardware 
illustrated  in  Figure  3-2  is  presented. 

The  GPDS-DS  hardware  includes  the  following  components: 

a.  Data  General  ECLIPSE  S/130  processor; 

b.  10-Megabyte  Disk  Cartridge  System; 

c.  7-Track  556/800  bpi  Magnetic  Tape  Unit; 

d.  2-Data  General  Dasher  Terminal  Printer  Consoles: 

e.  Data  Automation  Datatrack  36"  x  48"  Absolute  Digitizing 
Table: 

f.  Tektronix  4014-1  Graphic  Display  Terminal;  and 

g.  CALCOMP  1051  Drum  Plotter  with  CALCOMP  Microprocessor  Interface 
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Figure  3-2.  GDPS-DS  Hardware  Configuration 
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3.3  DLMS-PS 


The  DLMS-PS  hardware  configuration  (reference  Figure  3-3)  includes 
the  following  components: 

a.  Data  General  ECLIPSE  S/250  processor  with  integral  array 
processor  and  Floating  Point  Hardware; 

b.  10-megabyte  Disk  Cartridge  Subsystem; 

c.  7-Track  556/800  bpi  Magnetic  Tape  Unit; 

d.  2  -  9-track  800/1600  bpi  Magnetic  Tape  Units; 

e.  Data  General  Terminal  Printer  Console; 

f.  Data  General  300  LPM  Printer; 

g.  Data  General  192  Megabyte  Disk  Subsystem; 

h.  Tektronix  4014-1  Graphic  Display  Terminal; 

i.  Tektronix  4631  Hard  Copy  Unit  (Shared  with  GDPS-DS) ;  and 

j.  CALCOMP  1051  Plotter  (shared  with  the  GDPS-DS). 
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FUNCTIONAL  OVERVIEW 


4.1  6DPS-DS  Functions 

4.1.1  Digitizing  Functions 

The  digitizing  functions  are  conducted  on  the  GDPS-DS  in  an  inter¬ 
active  environment.  Initialization  and  Registration  modes  are  the  first 
functions  performed  in  a  GDPS  job  session.  Depending  on  whether  a  new 
job  is  to  be  created  or  an  existing  job  is  to  be  updated,  these  functions 
allow  for  parameters  to  be  entered  or  edited  and  for  registration  or  re¬ 
registration  to  occur. 

The  Header  function  is  the  central  mode  of  operation.  From  this 
function,  several  processing  paths  are  open  to  the  operator  for  lineal 
or  point  digitizing,  review,  and  editing.  The  transfer  of  control  from 
one  mode  of  operation  to  another  is  performed  using  the  pushbuttons  on 
the  digitizing  cursor. 

4. 1.1.1  Initial Ization 

This  function  determines  a  job's  new/old  status  and  creates  or 
updates  a  specific  job's  parameter  information.  The  parameter  file 
resides  oh  disk  and  is  updated  with  user  inputs  obtained  through  prompts  on 
the  display  terminal.  These  inputs  include  Job  ID,  chart  scale,  UTM 
reference  points,  and  other  geographic  data  including  corner  latitude/ 
longitude  coordinates,  and  UTM  zone  data  among  others.  After  all 
parameter  information  is  input  the  user  may  review  and  change  selected 
fields. 

4. 1.1. 2  Registration 

The  registration  software  sets  up  the  transformation  equations 
necessary  for  the  conversion  of  data  input  from  the  digitizer  to  the 
job's  geographic  frame  of  reference.  This  is  done  by  selecting  six 
points  on  the  digitizer-based  graphic,  associating  them  with  known 
geographic  UTM  coordijiates  and  deriving  the  appropriate  equations. 

The  geographic  registration  is  done  only  once  for  each  chart 
to  be  digitized.  Transformation  coefficients,  adjustments  and  corrections 
are  stored  in  the  job  parameter  blocks.  In  addition,  registration  refer¬ 
ence  points  collected  in  this  function  are  used  by  the  DLMS  processing 
subsystem  to  convert  from  table  to  geographic  coordinates.  Subsequent 
6-point  re-registrations  allow  for  a  table-to-table  transformation 
necessary  when  the  table-based  manuscript  is  removed  and  later  remounted. 


4. 1.1. 3  Header 


The  Header  function  is  used  in  the  assignment  of  headers  and  for  FAC 
(Feature  Analysis  Code)  numbers  to  features  prior  to  their  digitization. 
It  is  also  the  central  mode  of  user  operation  and,  through  this  function, 
access  is  made  to  the  Trace,  Discrete  Point,  Review  and  Edit  functions. 

Additionally,  a  menu  of  auxiliary  functions  can  be  accessed.  These 
auxiliary  functions  allow  the  user  to  establish  or  change  selected  job 
parameters  during  the  digitizing  session.  These  parameters  include 
changes  in  elevation  value,  contour  interval,  and  display  scale. 

4. 1.1. 4  Trace 


The  Trace  function  is  used  to  acquire  lineal  and  areal  features.  The 
features  are  stored  as  lineal  data  strings.  This  function  accepts  an 
x,y  coordinate  pair  derived  from  the  digitizing  table,  rounds  the  point 
to  the  nearest  multiple  of  the  recording  resolution,  then  packs  and  stores 
the  data. 

Points  are  input  to  the  Trace  function  from  either  continuous  stream 
digitization  or  an  alternate  mixed  point/ continuous  digitization  method. 
Each  point  is  displayed  on  the  console  screen  as  it  is  stored.  Exits  to 
the  Header  and  Edit  functions  are  provided  through  cursor  pushbutton  logic. 

4.1 .1.5  Discrete  Point 


The  Point  function  is  used  to  record  discrete  point  features.  Points 
recorded  from  the  digitizing  table  are  displayed  on  the  display  screen 
relative  to  their  table  position.  Point  labels  also  appear  on  the  screen 
The  points  are  then  open  to  sequential  cancellation,  if  desired.  As  in 
the  Trace  functions,  exit  to  the  Header  function  is  provided. 

4.1 .1 .6  Review 


The  Review  function  is  used  to  examine  features  collected  within  a 
user-specified  area  on  the  digitizing  table.  Additional  capabilities  of 
this  function  are  options  to  change  the  display  scale,  move  the  display 
window  and  exit  to  the  Header  mode. 

4. 1.1. 7  Edit 


The  Edit  function  provides  diverse  editing  activities  which  are  both 
feature-dependent  and  feature- independent.  General  Edit  functions  perform 
initialization  of  the  edit  process  by  locating  the  user-specified  feature, 
displaying  it,  determining  feature  type  and  permitting  header  change  or 
feature  deletion. 

Discrete  point  features,  once  located,  are  drawn  on  the  display  screen 
as  a  series  of  plus  signs.  A  square  is  drawn  around  the  point  selected  for 
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editing.  Points  may  be  deleted,  modified,  or  added  by  depressing  the 
appropriate  pushbutton  on  the  digitizing  cursor.  When  satisfied  with 
all  edits,  or  at  any  time  in  between,  the  user  may  redisplay  the  feature. 
Exits  to  Edit  or  Header  modes  are  provided. 

Trace  features  are  displayed  on  the  console  screen  as  continuous  line 
segments.  Prefix,  suffix,  or  mid-segment  edits  may  be  performed  on  trace 
features.  As  the  edit  segment  is  digitized,  it  is  displayed  on  the  screen 
for  verification.  Upon  completion,  the  operator  is  instructed  to  accept  the 
edit  and  return  to  Edit  mode;  reject  the  edit  and  return  to  Edit  mode;  or 
reject  the  edit  and  begin  digitizing  a  new  edit  segment. 

4.1.2  FADT  Processing  Functions 

The  FADT  processing  software  creates  and  assigns  Feature  Analysis  Data 
Table  (FADT)  descriptors  to  planimetric  features  collected  in  the  digitizing 
process.  The  FADT  processing  software  consists  of  two  main  functions,  FADT 
Entry  and  FADT  Merge. 


4. 1.2.1  FADT  Entry 

FADT  data  consists  of  radar-significant  parameters  derived  from  photo¬ 
graphs  or  other  sources  and  formatted  by  the  feature  analyst.  The  Entry 
function  facilitates  input,  editing,  and  review  of  this  data  by  providing 
the  following  capabilities: 

a.  creation  and  update  of  FADT  files; 

b.  text-editing  support;  and 

c.  hardcopy  output  of  all  or  selected  FADT' s  within 
a  file. 

4. 1.2. 2  Merge 

The  FADT  Merge  function  is  used  to  integrate  into  the  header  section 
of  the  DLMS  feature  record  the  associated  entry  of  the  FADT  data  file. 
Matches  are  made  between  the  two  files  by  comparing  the  FAC  (Feature 
Analysis  Code)  number  of  each  DLMS  feature  with  the  FAC  numbers  of  the 
FADT  entries.  Any  FADT  entries  or  DLMS  features  that  are  not  matched  are 
reported  and  a  summary  listing  of  the  merged  file  is  produced. 

4.1.3  Digitized  Data  Plots 

Verification  plots  have  been  developed  to  help  minimize  the  errors 
that  could  occur  in  the  digital  input  data.  The  plots  consist  of  terrain 
or  culture  file  data  obtained  in  the  digitizing  job  session.  Plots  are 
output  to  the  Calcomp  1051  Plotter  and  include  annotation  indicating  file¬ 
name  and  date  and  time  of  plot. 


4.2  DLMS-PS  Functions 


4.2.1  Terrain  Functions 

DLMS  terrain  processing  is  the  process  by  which  data  files  con¬ 
taining  strings  of  lineal  data  from  the  GDPS-DS  are  transformed  into 
an  elevation  matrix.  One  matrix  covers  a  1°  X  1“  area.  For  every  manu¬ 
script  (data  file)  received  from  the  GDPS-DS  an  elevation  sub-matrix 
is  built.  Each  sub-matrix  is  then  merged  with  other  sub-matrices  to  form 
the  1®  square  matrix  file.  The  DLMS-PS  terrain  processing  consists  of 
four  major  functions  as  described  below. 


4. 2. 1.1  Transformation 


The  terrain  Transformation  function  is  the  process  by  which  a  terrain 
job  file  from  the  GDPS-DS  is  converted  to  an  elevation  sub-matrix.  This 
process  includes: 


a.  accepting  user  inputs  needed  to  set  up  the  sub-matrix  file 
and  its  associated  1°  square  matrix  filename; 

b.  converting  LTM  northings/eastings  to  WGS-72; 

c.  forming  the  normal  coefficient  matrix  and  solving 
for  polynomial  coefficients; 

d.  computing  grid  line  numbers  in  reference  to  the  sub-matrix 
file;  and 


e.  storing  the  converted  to  WGS-72  elevation  data  in  the 
appropriate  locations  of  the  sub-matrix  file. 

4. 2. 1.2  Alteration/Smoothinq 


Any  holes,  spikes,  anomalies  or  discrepancies  are  removed  from  the 
manuscript  sub-matrix  file  in  the  Data  Alteration/Smoothing  function. 

The  Integrated  Array  Processor  is  used  extensively  by  this  function.  An 
average  elevation  for  each  sub-matrix  file  record  is  calculated  and  used 
to  replace  null  elevations.  Each  vertical  string  of  records  is  exaunined 
and  a  convolution  is  performed  on  the  string.  Data  resulting  from  the 
convolution  is  scaled  down  to  cover  its  original  range  of  elevations. 


4. 2. 1.3  Sub-Matrix  Merge 

This  function  merges  a  user-specified  DLMS  terrain  sub-matrix  file 
into  its  associated  1°  square  matrix  file.  This  is  accomplished  by 
accepting  inputs  of  the  sub-matrix  filename  and  the  southwest  corner 
coordinates  of  the  1  degree  square  from  the  user.  The  appropriate 


location  in  the  1°  X  1°  matrix  file  is  computed  then  the  sub-matrix  data 
is  output  to  that  area. 

4. 2. 1.4  1-Deqree  Square  Output 

In  this  function  of  the  DLMS  processing  system,  the  1°  square  matrix 
is  output  to  tape.  GDPS-DS  terrain  data,  having  been  transformed,  "smoothed" 
and  merged  into  a  matrix,  is  formatted  according  to  the  DMA  Standard  for 
Digital  Terrain  Data.  The  formatted  data  is  written  to  a  9-track  tape  along 
with  user-supplied  header  and  trailer  information. 

4. 2. 1.5  Character  Elevation  Plot 


This  function  produces  an  alphabetic  character  printer  plot  for 
verification  of  a  DLMS  terrain  file.  Each  alphabetic  character  represents 
a  specific  range  of  elevations  as  determined  by  user  inputs.  Any  grid 
location  which  has  no  elevation  will  be  depicted  by  a  " . "  on  the  printer 
output.  Plots  may  be  produced  from  either  a  DLMS  sub-matrix  file  before 
or  after  the  "smoothing"  process,  or  from  a  1-degree  square  file  at  any 
time. 

4.2.2  Culture  Processing 

4.2.2. 1  Transformation 

The  culture  Transformation  function  performs  the  process  by  which 
digitized  .culture  data  is  transformed  into  absolute  geographic  coordinates. 
This  function  will  signal  an  error  condition  if  the  process  is  executed  on 
anything  other  than  a  culture  file  that  has  been  merged  with  an  FADT  file. 
All  digitized  table  points  are  converted  to  WGS-72  geographies  then  offset 
to  the  nearest  minute  south  and  west  from  the  southwest  corner  of  the  source 
manuscript.  Any  feature  that  crosses  a  map  boundary  is  "clipped”  back  to 
the  boundary  by  means  of  an  interpolation  technique  using  similar  triangles. 
Additionally,  DSI  (Data  Set  Identifier)  and  REG  (Registration)  records  are 
formatted  for  subsequent  output  to  tape. 

4. 2. 2. 2  String  Generation 

The  culture  String  Generation  function  converts  the  file  created 
in  the  culture  Transformation  to  DMA  Standard  Exchange  format.  The 
digitized  feature  oriented  file  is  converted  to  one  that  is  FAC  (feature 
analysis  code)  oriented.  In  this  process,  strings  which  belong  to  more 
than  one  physical  feature  are  detected.  FAC  headers  are  set  up  and  linked 
to  all  strings  belonging  to  that  FAC.  This  method  allows  duplicate  strings 
to  be  filtered  out  of  the  data  at  this  point.  FEA,  (Feature  Header)  SEC 
(Section) ,  and  DAT  (Data)  records  are  formatted  in  this  function  for  output 
to  tape. 
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This  function  uses  the  disk  files  created  in  the  proceeding  culture 
functions  as  input.  Since  the  culture  data  was  previously  formatted 
in  the  DMA  Standard  Exchange  format,  the  disk  records  are  simply  read 
then  written  to  the  output  tape.  One  culture  output  file  contains  data 
pertaining  to  one  digitized  source  manuscript  as  opposed  to  a  terrain  output 
file  which  contains  data  in  a  1-degree  square  area. 

4. 2. 2.4  Verification  Plots 

Two  plots  are  available  for  verification  of  culture  data  processing- 
Following  the  Transformation  function,  the  geographies  generated  as  a 
result  of  the  transformation  process  may  be  plottted  on  the  Calcomp  plotter 
for  visual  verification.  Duplicate  strings  are  still  present  at  this  point 
but  features  will  be  "clipped"  to  the  manuscript  boundaries. 

Following  the  culture  String  Generation  function,  another  Calcomp  plot 
is  available  to  verify  the  format  and  contents  of  the  output  data.  This 
plot  is  also  capeible  of  plotting  data  directly  from  the  culture  output  tape. 
At  this  stage  of  culture  processing  any  duplicate  strings  should  be  removed. 
Additionally,  string  ID's  and  the  number  of  features  to  which  the  string 
belongs  are  output  to  the  printer. 


5.  TESTING/EVALUATION 


5.1  Test  Data 


since  the  IAF~GDPS  was  originally  intended  to  support  the  conversion 
of  Italian  manuscript  information  to  digital  DLMS  products,  Synectics 
attempted  to  obtain  typical  Italian  charts  (IGMI  1:25000  and  1:50000  scale) 
and  Feature  Analysis  Data  Table  (PADT)  data.  When  it  was  learned  that 
these  sources  were  not  available  within  the  scheduled  timeframe  for  data 
analysis  and  testing/evaluation,  Synectics  requested,  through  the  RADC  Project 
Engineer,  manuscripts  and  FADT  information  from  the  U.S.  production  centers 
(DMAAC  and  DMAHTC) . 

Manuscripts  to  support  the  testing  of  terrain  inputs  were  furnished  by 
DMAHTC.  These  manuscripts,  or  film  positives,  were  supported  by  litho¬ 
graphic  charts,  which  provided  a  geographic  base.  Culture  data  (overlays 
and  FADT  data)  were  provided  by  DMAAC. 

Several  steps  were  necessary  to  prepare  these  sources  to  a  form  accept¬ 
able  to  the  GDPS.  Primarily,  the  GPDS  had  been  implemented  to  support  pro¬ 
cessing  of  Italian-series  charts  within  the  geographic  locality  of  Italy. 

The  geographic  transformation  modules  were  then  modified  to  accept 
the  WGS-72  and  Tokyo  datums  instead  of  the  European  datiun.  In  addition, 
the  manuscripts  selected  by  Synectics  for  culture  test  input  did  not 
have  a  geographic  base  (no  corresponding  litho  sheets) ,  so  Synectics  project 
personnel  assigned  UTM's  and  geographic  reference  points  based  on  the  terrain 
input  test  data  base.  Acceptability  could  then  be  determined  by  confirming 
that  the  format  of  the  output  products  matched  the  DLMS  specifications. 

In  addition,  using  the  proof  plot  facilities  of  the  system  would  provide  a 
good  perspective  of  the  overall  data  at  its  various  stages  of  conversion. 


5.2  Test  Procedures 


Testing  was  accomplished  in  accordance  with  the  approved  Test  Plan; 
that  is,  both  non-operational  and  operational  tests  were  conducted.  Non- 
operational  tests  are  tests  which  can  be  carried  out  by  performing  visual 
inspections,  while  operational  tests  are  tests  which  are  based  on  system 
performance. 

Further  testing  was  performed  to  scrutenize  the  more  salient  aspects 
of  the  system,  such  as  culture  string  generation  (segments  to  FAC  feature 
conversion)  and  array  processing  support  of  the  data  alteration  module  used 
in  terrain  processing. 
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5.3  Test  Results 


In  all  but  a  few  instances,  the  results  generated  passed  acceptance. 
In  the  remaining  cases,  acceptable  results  were  gained  by  minor  software 
changes  and  by  a  further  delineation  or  clarification  of  operator  instruc¬ 
tions.  The  results  were  verified  by  performing  data  block- to-block 
comparison  with  the  DLMS  product  format  requirements  and  visual  inspec¬ 
tion  of  output  plots. 
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6.  CONCLUSIONS  AND  RECOMMENDATIONS 

6.1  Conclusions 


The  GDPS  has  successfully  demonstrated  that  DLMS  processing  can  be 
effectively  performed  on  a  dedicated  mini/midi  computer  consisting  of 
modern  off-the-shelf  technology.  In  addition,  it  has  been  shown  that 
state-of-the-art  architectures,  such  as  array  processor  augmentation/ 
integration  can  be  exploited  very  effectively  in  increasing  DLMS  processing 
performance  orders  of  magnitude  over  conventional  main  frame  computer 
organization. 

An  equally  important  conclusion  is  that  new  methods  in  preparing  DLMS 
data,  such  as  segment  digitizing  and  segment  (string)  generation  to  FAC 
features  can  eliminate  some  of  the  inherent  DLMS  problems  such  as  overlap/ 
gap  occurrences  between  culture  features.  New  processing  approaches  lend 
themselves  readily  to  minicomputer  implementation  for  the  following  reasons 

a.  there  is  more  interaction  between  the  developer  and 
the  computer; 

b.  there  is  less  "interference"  (resource  allocation,  scheduling, 
etc)  from  other  users;  and 

c.  there  would  be  negligable  effect  on  production  schedules,  say, 
on  a  GDPS- like  system  at  the  DMA  production  centers,  since 
production  runs  could  continue  while  new  processing  methods 
were  undergoing  development,  testing,  and  evaluation.  Once 
proven,  they  could  be  implemented  in  an  operational  software 
package. 


6.2  Recommendations 

The  decision  to  retain  the  GDPS  at  the  Experimental  Cartographic 
Facility  has  put  RADC  in  an  excellent  posture  for  future  applications 
and  research  in  digital  product  processing,  supporting  diverse  MC&G 
and  tactical/strategic  requirements.  The  remaining  pages  of  this  report 
are  recommendations  to  fully  exploit  the  features  of  the  GDPS  and  bring 
to  the  surface  the  latent  capabilities  of  the  system  hardware  and  software. 


6.2.1  "Americanization"  of  the  GDPS 

The  GDPS  was  designed  to  handle  the  IGMI  Carto  d' Italia  series 
1:25000  and  1:50000  chart  inputs.  A  UTM  registration  was  used  based 
on  the  European  Datum  and  International  Ellipsoid.  In  order  to  handle 
typical  American  charts,  the  registration  software  should  be  supplemented 
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as  follows: 


a.  The  inclusion  of  more  chart  scales; 

b.  More  projections,  such  as  Mercator,  Lambert  Conformal, 
and  Gnomon ic; 

c.  Additional  models,  such  as  Clark  1866,  etc., 

Bessel,  and  WGS-72/80. 

Corresponding  modifications  would  be  made  to  the  DLMS  culture  and  terrain 
transformation  modules  to  accept  these  inputs. 


6.2.2  Analysis  of  GDPS  Products 

Once  the  GDPS  was  "Americanized"  a  thorough  study  of  its  capabilities 
could  be  conducted  using  many  sources  comparable  to  those  used  for  input 
at  DMA  production  centers.  Accuracy  and  performance  characteristics  could 
be  systematically  checked  using  both  Level  1  and  Level  2  data. 


6.2.3  Analysis  of  DLMS  Products 

The  GDPS  is  the  logical  facility  for  further  research  and  develop¬ 
ment  of  DLMS  products  and  specifications.  The  culture  format  used  by 
the  GDPS  was  designated  as  a  draft  specification.  Further  refinements 
could  be  developed  and  tested  on  this  system  without  adversely  affecting 
ongoing  production  at  the  Centers. 


6.2.4  Test  Data  Base  Generation 


RADC  can  use  the  GDPS  to  build  an  in-house  DLMS  Carto  Data  Base. 
This  CDB  can  support  the  testing  and  evaluation  of  ongoing  and  future 
tactical  and  strategic  applications  efforts  in  an  environment  offering 
more  control  and  faster  response  since  data  base  files  can  be  accessed 
locally  or  be  generated  in  parallel  with  the  project  software. 


6.2.5  GDPS  Utilization  at  the  DMA  Production  Centers 

The  Cartographic  Processing  System  (CPS) ,  which  is  intended  to 
boost  the  production  rate  of  DLMS  Culture  data  base  files,  is  currently 
under  development  and  is  an  estimated  two  to  three  years  away  from 
production  level.  In  the  interim,  a  system  such  as  the  GDPS  could  be 
used  to  provide  rapid  throughput  of  ad  hoc  DLMS  products  requiring  high 
priority  without  affecting  the  normal  UNIVAC  1110  production  processing. 


C' 
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6.2.6  C^I  Requirements 


RADC  has  been  designated  by  APIS  as  the  responsible  agency  for  deter¬ 
mining  map  accuracies,  precision,  and  applicability  for  strategic  and 
tactical  weapons  requirements.  GDPS  system  elements  (hardware  and  soft¬ 
ware  modules)  are  ideal  building  blocks  in  constructing  new  products  or 
product  modifications  and  in  evaluating  the  degree  of  support  those 
products  furnish  in  meeting  these  requirements. 
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MISSION 

of 

Rome  Air  Development  Center 

RAOC  ptanA  and  axecateA  aeAexvich,  deveZopment,  teAt  and 
AiZtcXed  acquUAltcon  ptLogfiam  In  Auppont  Command,  Contxot 
CotimanLcationA  and  InteZLigunta  (C^I)  actio itlzA .  Technical 
and  cngtneelung  AuppoAt  within  okcoa  technical  competence 
iA  provided  to  ESP  Pfiogfiam  O^^iceA  (POa)  and  otheA  BSD 
elementA.  The  ptiincipal  technical  miAAion  aAeoA  a>ie 
cornmanlcationA ,  elecikomagnetic  guidance  and  control,  aua- 
vetUance  ground  and  ae^oApace  ob/ectA,  intelligence  data 
collection  and  handling,  information  AyAtem  technology, 
ionoApheiUc  propagation,  Aolid  a  tote  ActenceA,  microwave 
phyAicA  and  electronic  retiabitity ,  maintainability  and 
compatibility. 


